1. Field of the Invention
The present invention relates to a method and framework for code testing in general, and to testing object code without additional layers in particular.
2. Discussion of the Related Art
Code testing is a major part in the development cycle of computer programs. Testing is a process intended to reveal and enable the correction of faulty behavior, problems, inefficiencies and other quality-related issues about the product. Adequate testing is essential for assuring proper performance of the written code. Testing generally starts with testing the smallest possible units, called “unit test”, which is usually done by the code developer, and continues with integration testing, system testing, and acceptance testing, which should comprise following test plans or test scenarios associated with the system. However, proper testing, at all levels, requires human and time resources which are often not allowed enough time for. As a result, code is often tested only in a number of a-priori known scenarios which may not be sufficient, so that certain parts of the code are not executed and problems or bugs are not trapped until other programmers' codes are involved. Such bug may present itself only much later in a more complex situation, wherein the bug trapping is much more complex, time consuming and expensive, and its correction may involve major change in the system. Further problems result from changes to existing code, which are believed to be insignificant, so intensive regression tests are not performed, but they may introduce new bugs. Testing is often performed only when user interface, whether the final user interface of the product or an earlier version thereof is available for activating the code. Thus, a programmer writing “internal”, i.e. non-user-interface code may postpone testing his code until a much later time. In addition, the user interface and the tests designed for the user interface may not activate each and every command, so that certain parts may be activated for the first time in unexpected situations, and provide unexpected behavior. Another option for testing code requires inserting additional code, required only for testing. However, this is a tiring process which is seldom performed diligently and intelligently enough to cover all possibilities. Further, such code slows the execution and demands maintenance. Keeping a dedicated “debug” version, wherein the “regular” version lacks the debugging code is either impossible or introduces new errors into the code. The situation is no different when object oriented code is involved. For clarity, the term method in the context of object-oriented programming will be referred to as “operation”. In the absence of user interface which activates operations of the business-related objects, or having a user interface that does not cover all functionality of the code in all situations, some operations are not tested at all, while others may be partially tested, or tested during creation but neglected later on in further situations.
There is therefore a need for a method and framework or apparatus for testing object oriented code by activating all required object operations in an automated fashion without requiring a programmer to write and maintain neither user interface code nor dedicated testing code. The method and apparatus should support performing tests and checking whether the tested code produces the expected results, both for unit tests and for complex test plans for scenarios of the system. If the expected results are not produced, the method and apparatus should point at the failure by indicating which operation or property of which object caused the failure. The tests should be reproducible so a bug report can be sent to a programmer together with the exact testing scenario that caused the bug, thus eliminating complex, time-consuming, and not necessarily successful reproductions. The method and apparatus should be applicable to all level of testing, whether unit test, integration test, system test or acceptance test.